This is a comment left during a code review.
Path: crates/project/src/configuration.rs
Line: 1016-1018

Comment:
**`"fast"` alias silently repurposed — existing recordings may change animation feel**

The `"fast"` serde alias was previously an alias for `Mellow` (high-damping, tension 470 / mass 3.0 / friction 70). It's now removed from `Mellow` and instead matched by the new `Fast` variant (tension 380 / mass 1.0 / friction 30) via exact-string deserialization.

Any project JSON on disk that stores `animationStyle: "fast"` (from legacy tooling or manual edits) will silently switch from Mellow's parameters to Fast's. The user-visible UI never exposed `"fast"` as a string value (the old TS type was `"slow" | "mellow" | "custom"`), so real-world exposure is low — but a defensive serde alias on `Fast` would make the migration explicit:

```rust
#[serde(alias = "regular", alias = "quick", alias = "rapid")]
Mellow,
// intentionally repurposed from legacy Mellow alias:
Fast,
```

At minimum, a comment noting that `"fast"` is intentionally repurposed rather than a retained alias would help future readers understand the decision.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: crates/rendering/src/zoom_focus_interpolation.rs
Line: 1554-1556

Comment:
**Dead storage fields kept with underscore prefix**

`_precomputed_cursor`, `_cursor_smoothing`, and `_click_spring` are now stored in the struct but never read. They're passed in through both `new_arc` and `new_arc_with_precomputed_cursor`, allocated on every instantiation, and held for the lifetime of the interpolator — but the code that consumed them (`interpolate_cursor_at`) was removed in this same PR.

If these values are genuinely no longer needed, removing them from the struct and call sites cleans up the API and avoids unnecessary `Arc` ref-count bumps. If they're intentionally parked for a future feature, a `// TODO:` comment tracking the intent would be helpful so they don't accumulate indefinitely as silenced dead code.

The same applies to the corresponding call site in `playback.rs` where `cursor_smoothing` is computed a second time inside `build_zoom_interpolators` solely to pass into `ZoomFocusInterpolator::new_arc_with_precomputed_cursor` where it goes unused.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: crates/rendering/src/zoom.rs
Line: 62-64

Comment:
**Unused public parameter in `from_segment_with_cursor_constraint`**

`_actual_cursor` is now entirely unused inside the function — the whole `calculate_zoom_and_center_for_cursor` branch it previously fed was removed. As a `pub` function its signature is part of the crate's interface, so leaving a permanently ignored parameter can confuse callers about what they're expected to provide.

If the parameter has no planned future use, consider removing it from the signature and updating all call sites. If it's intentionally kept as a hook for future work, a `// TODO:` comment explains the intent.

```rust
pub fn from_segment_with_cursor_constraint(
    segment: &ZoomSegment,
    zoom_focus: Coord<RawDisplayUVSpace>,
-   _actual_cursor: Option<Coord<RawDisplayUVSpace>>,
) -> Self {
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: apps/desktop/src-tauri/Cargo.toml
Line: 3

Comment:
**Unusual version bump `0.4.8` → `0.4.81`**

Semver patch increments conventionally go `0.4.8 → 0.4.9`. Jumping to `0.4.81` (skipping 72 patch levels) is valid semver but looks like either a typo (`0.4.9` was intended) or a deliberate "sub-patch" scheme. If this is intentional (e.g., rapid hotfix numbering), a comment or convention note in the release process would prevent future confusion.

How can I resolve this? If you propose a fix, please make it concise.